REMARKS 

The Office Action of July 12, 2005 has been carefully 
considered . 

Claims 1-11 have been rejected under 35 USC 112, 2 nd 
paragraph, as omitting the essential step of adding a header 
after segmentation of the bit stream. 

Claim 1 has now been replaced by new claim 17, which does 
not recite a header, and therefore, no essential steps have 
been omitted. Withdrawal of this rejection is requested. 

Claims 1, 3, 4, 7, 9 and 20 have been rejected under 35 
USC 102(e) over Ravikanth, and claims 12 and 14-16 have been 
rejected under 35 USC 103(a) over Ravikanth. 

The invention relates to a method for packet processing 
for data transmission over an optical fiber. The method 
includes forming a novel form of packets which can be treated 
as if they were conventional packets for purposes of 
encapsulation, routing, and transmission on a communications 
network (page 6, lines 4-7) . The heart of the invention lies 
in the formation of these novel packets, each of which 
includes a segment of a bit stream in its original protocol. 
This segmentation is done to optimize utilization of the 
available bandwidth of the optical fiber, as now recited in 
claims 17 and 19. 

Thus, the invention is directed to a method for packet 
processing for data transmission over an optical fiber, the 
method including the steps of 1) receiving an incoming bit 
stream of data of at least one service, 2) segmenting the bit 
stream in its original protocol into variable length segments 
according to available transmission bandwidth, 3) adding a tag 
identifying a route between a source and a destination end- 
point of the bit stream, and 4) processing each such segment 
for transmission in a transmission frame. Once the packets are 
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formed, they can be treated by conventional methods, e.g., 
encapsulating the tagged segment into a Point-to-Point 
Protocol (PPP) packet in a frame, and mapping the encapsulated 
packet into a transmission frame for transmission over an 
optical fiber. (See, for example, page 3, lines 20-25 of the 
application.) Support for the amended claims can be found on 
page 3, lines 20-22, page 6, lines 10-16, page 7, lines 17-22, 
page 8, lines 1-7, and page 8, lines 23-24 of the 
specification . 

Conventional packets are known only for certain data 
services, particularly Ethernet and Fibre channel packets. 
Other services are divided in different fashions, for example, 
TDM services are divided into time slots, and ATM services are 
divided into cells. As stated in the Background of the 
Invention (page 1, lines 16-19), at present, data according to 
each protocol must be transmitted via its own network, and 
data at different bit rates must be transmitted separately or 
processed before being transmitted simultaneously with other 
data rates and/or types over a higher bit rate medium. Thus, 
in conventional methods, utilization of bandwidth during 
transmission of various services over a common optical fiber 
system is inefficient, as not all the bandwidth is utilized 
due to empty portions of packets, time slots, and/or cells, 
etc. The invention, by creating novel packets, permits 
services, in their original protocols, to be divided up into 
different size units, so that "empty" spaces on the bandwidth 
can be filled, thereby increasing efficiency of the overall 
system. This method permits the data received in a variety of 
different protocols from a variety of different services to be 
combined into packets without regard to their original 
protocols. In addition, (except for TDM services, which 
require synchronization) , even single services can be 
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segmented into smaller units for more efficient utilization of 
network resources than is possible at present. 

The Office Action alleges that Ravikanth discloses a 
method for data transmission comprising adding a label to the 
front of a datagram, where adding a label is interpreted as 
adding a tag, and where the datagram is interpreted as a 
segment. The presence of a datagram has also been interpreted 
as being preceded by a form of segmentation of a data stream. 

The patent to Ravikanth utilizes datagrams which are pre- 
formed conventional packets, and can only be utilized with IP 
packets (packet-based services) . The presence of a datagram 
does not teach or suggest receiving an incoming bit stream of 
data of at least one service, segmenting the bit stream in its 
original protocol into variable length segments, and adding an 
identifying tag, before processing the segment for 
transmission, as is claimed. Rather, the packet based 
services which are provided as datagrams in Ravikanth can be 
subsequently segmented according to the present invention and 
formed into the novel packets of the invention, alone or with 
packets of other types of services. 

In the Office Action, on page 9 it is stated that 
"Ravikanth does teach the segmentation of bit streams as 
indicated above" (3-4 lines from the bottom) . The Office 
Action has interpreted the presence of a datagram as being 
preceded by a form of segmentation of a bit stream. Ravikanth 
does NOT teach segmentation of bit streams (i.e., into 
packets) ; the reference only teaches treatment of pre-formed 
packets in the form in which they arrive. The invention, to 
the contrary, teaches segmenting bit streams into a novel type 
of packet based on optimization of bandwidth, which can then 
be treated like a conventional packet. 
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Ravikanth teaches how to map IP service packets over 
Ethernet onto SDH (transmission frames) by adding a label at 
the start and, since the packets are of variable length, a 
label at the end. But Ravikanth can only use complete packets 
as received and does not segment the packets for any reason. 
According to the claimed invention, the bit stream (or 
streams) is cut into segments of a selected size and tags are 
added to permit optimization of available bandwidth for more 
efficient transmission (and to combine multiple services, when 
desired) . 

In the example discussed in the Office Action, it appears 
that the bit stream has not been segmented, but rather the 
frame was used as is. In this example, the selected segment 
happens to be the same size as an Ethernet packet. In other 
words, in some cases, the full frame can be taken as the 
segment and "packetized", and in this regard, the frame can be 
"equal" to a packet. Nevertheless, the segment is processed by 
the claimed operations, which still differ from those of 
Ravikanth. However, those skilled in the art will appreciate 
that ALL Ethernet packets (as a service) are the same in ALL 
applications, while the segment according to the invention can 
be any selected portion of a conventional Ethernet packet or 
other service bit stream. 

The Office Action further states that "it is also clear 
that" the incoming traffic has a format determined in advance. 
This is not clear at all; it may occur in a particular 
example, but the next Ethernet frame received could just as 
easily be segmented into smaller segments, and not remain as a 
whole frame. 

The Office Action alleges that it would have been 
impossible to recognize which service the bit streams belong 
to without a previously established format, so that the 
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segmentation can be according to the type of service. It is 
then noted that the claimed segmenting of the bit stream is 
equivalent to recognizing the different services, and 
concludes that bit streams are pre-formed prior to tagging in 
the same manner of the datagram of Ravikanth. This is not 
correct. It may true that each service has an established 
format by which it can be recognized, but recognizing which 
data service is arriving has no relationship to utilizing 
datagrams or to making novel packets of variable bandwidth. In 
any event, "datagrams" are only relevant for Ethernet services, 
and not for TDM over SDH services or for Storage, or other 
types of services. 

Regarding the allegation that Ravikanth teaches 
encapsulation of datagrams of different lengths (figure 3), 
and that MPLS of different length packets is clearly for 
different data services, this is also incorrect. To state 
that Ravikanth "provides for different services regardless of 
the payload protocol type" indicates a misinterpretation of 
the reference, since while the payload being carried in 
Ravikanth can be "any network layer protocol," the protocols 
involved are only for IP service. The fact that Ravikanth 
doesn ! t look inside the payload, not only does NOT inherently 
provide for different services, but is only possible because 
he can process only a single service. Ravikanth thus takes 
pre-formed IP service packets and adds an MPLS label for label 
switching over serial links. Ravikanth 's datagrams may, 
indeed, be of variable length, but they are received that way 
and transmitted that way, without regard to utilization of 
bandwidth . 

The invention takes bit streams of one or more services 
and segments them to form a new unit which can then be 
manipulated as if it were a conventional packet, even though 



10 



it is not. In this way, units of different sizes can be 
combined to optimally fill the available bandwidth. This is 
the only way to multiplex different services in one bit 
stream. 

With regard to the apparatus claims, the Office Action 
alleges that it would be obvious to provide an engine having 
modules to carry out the method of Ravikanth. The method of 
Ravikanth has been described above, and an engine provided to 
carry out the method of Ravikanth would not include the 
crucial service port and segmentation module of the invention 
for receiving and segmenting an incoming bit stream of data o 
at least one service in its original protocol. 

The Office Action points to the non-limiting Example in 
the application which utilizes an Ethernet frame as a 
"segment" for purposes of creating a packet, and alleges that 
the M [E]thernet frames are received as a segment with the 
identifying information." Applicants submit that this is not 
accurate. The Ethernet frame is received and may be used, in 
its entirety, as a segment for purposes of the present method 
However, as stated on page 6, lines 15-16, for services such 
as Ethernet, the segments can have variable length within the 
particular service, so the frame can be cut into several 
segments as required to optimize bandwidth. There is no 
indication in the present application that the format must be 
determined in advance, as is, indeed, the case in Ravikanth. 
Rather, the length of the segments may be determined at the 
time of filling the transmission frames so as to fill, as 
completely as possible, the bandwidth in each frame. 

Withdrawal of these rejections is requested. 

Claims 2, 5, 6, 11 and 13 have been rejected under 35 
U.S.C. 103(a) over Ravikanth in view of Ndousse. The Office 
Action alleges that Ravikanth fails to disclose the use of 
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HDLC frames, which are disclosed by Ndousse. 

Both Ravikanth and Ndousse disclose using packets over 
SONET/SDH. The Ndousse article on PPP Extensions examines the 
dynamics of IP traffic over SONET/SDH using PPP in HDLC-like 
framing. There is no teaching or suggestion in Ndousse of the 
method of forming the novel packets of the invention, and thus 
the combination of Ravikanth and Ndousse does not result in 
the novel single or multi-service packets having segments of 
variable length in their original protocols of the present 
invention, but only previously prepared, conventional single 
service packets. 

Withdrawal of this rejection is requested. 

In view of the foregoing amendments and remarks, 
Applicants submit that the present application is now in 
condition for allowance. An early allowance of the 
application with amended claims is earnestly solicited. 
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Respectfully submitted, 
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